【AWS】SQSキューの前には難しいこと考えずにSNSトピックを挟むと良いよ、という話

都元ダイスケ

2014.08.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

よく訓練されたアップル信者、都元です。SQSはみなさん使われていますでしょうか。複数のコンポーネント間の疎結合を保ち、バッチ処理等の冗長性・拡張性を確保するために必要不可欠なサービスです。

SQSの活用イメージにつきましては、AWSでジョブWorkerを構成するベストプラクティスのSQSの巻やBeanstalk worker tierの巻をご覧いただくと良いと思います。

さて。SQSを使うぞ、ということになった場合。メッセージを投げる側（＝プロデューサ）と、メッセージを受け取る側（＝コンシューマ）が必要です。どこかから持ってくる（実装済みの既成品を探してくる）か、もしくは自分自身で実装するわけです。

もちろん、プロデューサはSQSのインターフェイス（API）を理解し（依存し）ていなければなりません。要するに、キューにメッセージを投入する方法を知っており、それを使ってメッセージを投げるような実装になっていなければなりません。同じように、コンシューマもSQSのインターフェイス（API）を理解し（依存し）ていなければなりません。要するに、キューにからメッセージを取得する方法に沿って処理を実装しなければなりません ^*1。

で。構成として「プロデューサ → SQS queue → コンシューマ」というのがシンプルで直球の実装であることには同意します。ですが本稿タイトルで主張しているのは「プロデューサ → SNS topic → SQS queue → コンシューマ」という形が良いよ、ということです。

えー、なんでそんなことを…。

ですよね。とりあえずこうすることによるデメリットを考えてみましょう。

SNS topicの構築（SQSとの連携設定等）の手間が増える
コンポーネントが増え、複雑性が増すため、トラブルの原因が増える
SNSの課金が余計に掛かる

まぁ、こういったデメリットは確かにあります。他にもあるかもしれません。思いついた方がいましたら教えて下さい。SQSのみを利用する構成からこの構成に移行する場合、プロデューサ側の改修が必要となるでしょう。ただ、依存が増えるわけではなく、SQSへの依存がSNSへの依存に変わるだけです。メッセージの送り方がSNS topicへのメッセージ投入方法に変わるだけです。

個人的な感覚に過ぎませんが、大して重大なデメリットは無いと思っています。手間に関しては私は慣れてますし（ぇ）、トラブルの経験もないですし、SNSの課金はむしろ安すぎてビックリですし。

一方、この構成のメリット

を考えてみましょう。

より抽象的

SNSにメッセージを送るプロデューサは、プロデューサのコードを改修することなく、送り先をSQS queue以外に変更できます。例えば「メッセージをメールとしてどこかに配信する」「Webサーバに対してHTTP POSTを投げる」等への変更が可能です。

一方、SQSにメッセージを投げるプロデューサは、改修を避けることができません。意地でも改修を避けるのであれば、queueからメッセージを受け取ってメールを送信するコンシューマを追加実装するハメになります。

というわけで、SQSに直接メッセージを投げるより、ひとまずSNSにメッセージを投げる実装のほうが抽象的で、高い拡張性を持つことが分かります。

ドレーニングポイント

プロデューサとコンシューマが両者とも（ある程度）健全に動いている時、queueを通過するメッセージを観察するのは困難です。プロデューサにより投入されたメッセージは、瞬時にコンシューマに受信され、メッセージはinvisibleとなります。この瞬間を突いてメッセージを見ることは困難を極めることでしょう。

invisibleの状態のメッセージは、外部から観察することができませんが、SNSをはさんで置くことにより、SQSにメッセージを送りつつ、同時に自分のメールアドレスにメッセージを送らせる等の方法により、キューに入ったメッセージを観察することができます。